In today's modern networks, it is quite common for network devices (also referred to as network elements or NEs) to be spread out over a wide geographical area. For example, one network element may be situated in New York, another in California, and another in Europe. Having network elements in such diverse geographical areas could result in the management of a network being difficult. To ease this managerial burden, many modern networks implement a remote management system. This management system, which could run from a computer connected to the network, enables a user to use the network to interact with and to remotely manage a plurality of network elements, regardless of where those elements are situated. With such a system, a user can manage an entire network conveniently and efficiently from a single centralized location if desired. This management system can be used to manage just a single network element or network of such network elements.
To enable a network element to be remotely managed, some additional functionality is imparted to the network element. This additional functionality is typically achieved through embedded management software. Specifically, the network element executes one or more programs that enable it to provide a set of management services. For example these services may include, support for functionality to monitor performance data, provision a connection or update one or more of the operational parameters of the network element to change the element's behavior etc. These services once available will be remotely invoked by the management mechanism (system) to achieve basic functionality as an element management system/network management system. Thus, by using the management mechanism to remotely invoke an element's management services, a user can remotely manage that element. Modern network management system usually supports OAM&P or FCAPS functionalities. OAM&P stands for Operations, Administration, maintenance and Provisioning. FCAPS stands for Fault Management, Configuration Management, Accounting Management, Performance Management and Security Management. Network management system provides necessary functionality for service providers to provision and maintain high levels of service.
In order to invoke the management services offered by a network element, the management mechanism needs to have information regarding what services are offered and how to invoke those services. Typically, the management mechanism executes one management program per network element specific to that network element with a specific release of software in order to manage it. The management program is hard-coded such that it has information regarding what services are offered by the network element, and how those services can be used. As noted above, the management mechanism gains the ability to remotely manage the network element. The management program is specific to a particular network element. Thus, to manage another network element, the management mechanism may need to execute another management program. Another typical approach is to write a wrapper application, which appears to be a single management system, but underneath the system there are separate applications for each type of network element and each major software version of the network element.
But a modern network may comprise many different types of network elements from different manufacturers and it may contain different versions of the same type of network elements within a network as well. For example, network elements may include optical cross connect, switches, routers, bridges, gateways, etc. Each type of element may perform different functions, have different releases of an operating system and hence, may have different aspects that need to be distinctly managed. As a result, each type of element may offer different remote management services. Even for the same type of element, the remote management services offered may differ from element to element. For example, different versions of an element's embedded system software (or operating system) may have different functionalities (e.g. a newer version of a router's embedded system software may have more functionality than a previous version of the same switch). Hence, the different versions of the element's embedded system software may offer different services to manage the different functionalities. Even where the same management services are offered, the manner in which the services are implemented may differ from one version of an element's embedded system software to another. For example, in a first version of a switch's embedded system software, a management service may use a particular data type, whereas in a second version of a switch's embedded system software, the same management service may use a different data type. As this discussion shows, there can be great variation in network element characteristics (e.g. element type, version, services offered etc.) across the various elements in a network.
As noted above, the management mechanism executes a management program specific to a particular version of the network element's embedded system software in order to remotely manage that element. If two network elements have identical characteristics from a remote management standpoint, then the management mechanism can execute the same management program to manage both elements. However, if any of the characteristics of the elements are different (for example, the elements are of different types (e.g., different product types), the versions of the elements' embedded system software are different, etc.), then the management mechanism will need to execute different programs within a management system to manage the different elements. As discussed previously, a network may comprise many elements with different characteristics. As a result, to manage all of the elements in a network, the management mechanism may need to execute a large number of different management programs. This imposes a heavy burden on the management mechanism in many respects, including heavy storage consumption (a complete copy of each management program needs to be stored), heavy memory usage (if a large number of the management programs are run concurrently and system memory can be quickly and completely consumed). These all contribute to degrading the performance of the management system and scalability become an issue. And for a large number of managed NEs, the system becomes very slow and practically useless.
The other significant drawback of the current approach is that development of management software is very tightly coupled with a specific type of NE and maintenance of such a system becomes increasingly difficult as more types of NEs and different versions of its embedded system software needs to be managed. Also development complexities increase since developers cannot work independently without knowing both the NE and the management system software. Any addition or modification of services to the NE will likely result in a need for a modification to the software. Also work of one developer will directly interfere with the change made by another and the management of the code base for the software becomes a fairly complex task directly resulting in exponentially increasing development time for small incremental changes to the system. Not only do modified services need to be tested, but existing functionalities also need to be re-tested to ensure the quality of the system. Therefore, this approach results in longer time to market as well as more development resources
In order to manage multiple NEs of either different types or different software versions, multiple such management systems need to be fully installed in order to manage those NEs and to ensure that the backward compatibility support, which is becoming increasingly important with centralized network management systems is also addressed.
An old alternative approach is to have a very thin wrapper layer which uses large and heavy NE specific programs to manage multiple NEs of different types and/or different versions. However, the draw back mentioned above also applies to this approach as well. Based on the foregoing, it is clear that the current methodology for remotely managing network elements has significant drawbacks. As a result, an improved approach is needed.